This invention relates generally to a method and system for booting a computer, and more specifically, to a method and system which ensures that the boot-up procedure will always be successful.
When a user starts a personal computer system, the computer system goes through a complex set of operations to make sure that all of its components are working properly. This operation is but the first step in an even more complicated process called the system boot-up procedure (i.e., the boot). Booting the system activates all of the computer system""s components long enough to load an operating system. The operating system is a computer program that allows the computer system to use other computer programs. Before attempting to load the operating system, the computer system insures that the system""s input-output hardware, central processing unit, and main memory are all functioning. This is accomplished through the use of a power-on self-test, or Post.
After the Post checks all of the hardware components of the computer system, a boot program contained in the computer""s ROM BIOS chips checks drive A of the computer to see if drive A contains a formatted floppy disk. If a formatted floppy disk is positioned in drive A, then the boot program loads the first sector of the disk into memory and executes it. If there is no formatted floppy disk in drive A, then the first sector on the first hard drive is loaded into memory and executed.
The first sector on the hard drive contains a program that reads the partition table of the hard drive and determines which partition is marked active. The first sector from the active partition is then loaded into memory and executed.
The first sector on the active partition or floppy disk contains a program that searches for files that comprise the first files of the operating system. On most personal computer systems, the files are named IO.SYS and MSDOS.SYS. On IBM computers, the two files are named IO.SYS and IBMDOS.COM. For purposes of this discussion, it will be assumed that the two system files are IO.SYS and MSDOS.SYS. IO.SYS provides a low level interface to the ROM BIOS device routines. MSDOS.SYS is the DOS program itself and provides a high-level interface for user programs. It consists of file management routines, data blocking/deblocking for the disk routines, and a variety of built-in functions easily accessible by user programs. When these function routines are invoked by a user program, they accept high-level information via register and control block contents, then translate the requirements into one or more calls to IBMBIO.COM to complete the request.
The boot record takes control of the computer system and loads the two operating system files into memory. The IO.SYS file contains extensions to the ROM BIOS and includes a routine called SYSINIT that manages the rest of the system boot procedure. After loading IO.SYS, the boot record is replaced in memory by other program code, and SYSINIT assumes control of the system boot procedure. In doing so, SYSINIT loads MSDOS.SYS into memory. SYSINIT then searches the root directory of the computer memory for a file named CONFIG.SYS. If CONFIG.SYS exists in the computer system, then SYSINIT requests that MSDOS.SYS execute the commands in the CONFIG.SYS file. CONFIG.SYS is a file created by the computer user and contains commands which tell the operating system how to handle certain operations, such as how many files may be opened at one time, and how many system buffers may be used at any one time. CONFIG.SYS also contains instructions to load device drivers. A device driver is a program that the operating system uses to control hardware that communicates with the computer system. For example, MS-DOS uses a device driver to control how information is written to and read from a floppy disk drive. MS-DOS also has built-in device drivers for the computer system keyboard, monitor, hard drives, and communication ports.
Next, SYSINIT tells MSDOS.SYS to load the file COMMAND.COM. One function of COMMAND.COM is to search the root directory of the computer memory for a file named AUTOEXEC.BAT. AUTOEXEC.BAT is a file created by the computer user and contains a series of MS-DOS batch file commands and/or the names of programs that the user wants to run each time the computer system is actuated. Typically, the computer system is now fully booted and ready to be used.
However, as new hardware components are added to the computer system or as user needs change, it becomes necessary to modify the two user created system boot files, CONFIG.SYS and AUTOEXEC.BAT. Prior art systems allow the user to add and change CONFIG.SYS commands or AUTOEXEC.BAT commands to configure the computer system to suit the user""s needs. To edit the CONFIG.SYS file, the MS-DOS editor or a text editor that saves files as unformatted (ASCII text) is typically used. Once the changes to the CONFIG.SYS file or the AUTOEXEC.BAT file have been completed, the user must restart the computer system in order to have the changes take effect because MS-DOS reads the CONFIG.SYS file and the AUTOEXEC.BAT file only during the boot-up procedure (i.e., when the computer system is started).
Occasionally, the changes to the CONFIG.SYS file or the AUTOEXEC.BAT file will cause the computer system to xe2x80x9changxe2x80x9d (i.e., not boot) in a way that prevents the user from editing, and therefore correcting, the system boot files. For example, in some cases where the system boot files are unusable, the device driver for the computer system""s hard drive cannot be loaded. Therefore, the system boot files stored on the hard drive cannot be accessed or edited. In order to overcome this deadlock the user must load an operating system such as MS-DOS from a floppy diskette. The user then edits the system boot files using the operating system editor and attempts to reboot the computer system using the edited system boot files on the hard drive. This process continues until the computer system is successfully booted.
It would be desirable to have a computer system which automatically boots even if some configuration data has become unusable so that the user of the computer system can access the system boot files without the need of loading additional files from external storage medium.
The present invention provides a method and system to boot a computer system even after some configuration data has become unusable. This is accomplished by a method and system for booting the computer system from a set of configuration data that last booted the system properly. The present invention first attempts to boot the computer system from a current set of configuration data. If the attempt is unsuccessful, the present invention automatically boots the computer system using the last set of configuration data which successfully booted the computer system and which was previously stored. In response to a successful boot of the computer system using the last set of configuration data that properly booted the computer system, the present invention makes a new current set of configuration data that is equivalent to the last set of configuration data that successfully booted the computer system.
If the attempt to boot from the current set of configuration data is successful, the present invention stores it as the last set of configuration data that successfully booted the computer system.